Large-scale, fault-tolerant audio conferencing in a purely packet-switched network

ABSTRACT

A method of large-scale fault-tolerant audio conferencing in an audio conferencing system using a purely packet-switched network. An endpoint places a call to a conference gatekeeper indicating an audio conference. The conference gatekeeper determines whether the call contains sufficient information to establish the audio conference. If there is insufficient information, the endpoint is connected to an IVR server that obtains sufficient information from the endpoint. Either way, a CACS selects an MCU hosting or that will host the audio conference. The CACS then responds to the endpoint with routing instructions indicating the selected MCU and the endpoint connects or transfers to the selected MCU. The MCU mixes input from all endpoints in the audio conference to form a voice stream, which is then returned to each endpoint in the audio conference. Audio conference participants can dial-out from the MCU to bring additional participants into the audio conference. Once established, the audio conference supports full service audio conferencing. In addition, dynamic routing permits an operator to service multiple MCUs, and an audio conference participant and/or an entire audio conference to be moved between MCUs. The audio conference can also be broadcast from a streaming protocol server to passive participants.

BACKGROUND OF THE INVENTION

[0001] 1. Related Application

[0002] This application is related to co-owned U.S. Patent Applicationentitled LARGE-SCALE, FAULT-TOLERANT AUDIO CONFERENCING OVER A HYBRIDNETWORK, filed on the same date as this application.

[0003] 2. Field of the Invention

[0004] The present invention relates generally to the field ofpacket-switched network audio conferencing. More specifically, thepresent invention discloses a method for large-scale, fault-tolerantaudio conferencing in a purely packet-switched network.

[0005] 3. Statement of the Problem

[0006] The most common method to route calls for an audio conference isto control a local switch in a GSTN (globally switched telephonynetwork). That is, a physical point-to-point connection is made betweeneach piece of equipment in the network to create an overallpoint-to-point audio connection for the call. However, such aswitch-controlled application can only route calls to devices connectedto the switch, limiting the overall size of the system and limiting thegeographic distribution of multipoint control units (MCUs) within thesystem. In addition, call transfer (e.g., from one MCU to another)requires that the connection from the switch to the new endpoint beestablished and the path to the transferring endpoint be torn down, thuslimiting its use in a large-scale audio conferencing system.

[0007] Another conventional method to route calls for an audioconference is to interface with the network signaling layer (SS7/C7)directly.

[0008] Packet-switched call routing, on the other hand, facilitatesdynamic call routing and call transfer during a call. That is, nodedicated point-to-point connection is required in a packet-switchednetwork. Each packet, including the call data and associated control, issent individually to a destination address and the physical route takenfrom one endpoint to another can vary from packet to packet, eliminatingthe need for a dedicated circuit for each call. Thus, a call can berouted or even transferred within the packet-switched network simply byrenegotiating the end point address. A need exists to provide audioconferencing using packet-switched call routing.

[0009] There is a need for audio conferencing implemented on a purelypacket-switched network that provides both scalability and faulttolerance. Specifically, a need exists to monitor a pool of MCUs todetermine which MCU can best handle the conference, and to dynamicallyroute calls within the purely packet-switched network so that aconference participant in one conference call can be transferred toanother conference call and further, entire conferences can betransferred to other MCUs in the MCU pool without interrupting the audioconference (i.e., without tearing down connections and reestablishingthe connections within the packet-based network). A need also exists foraudio conferencing for both receive-only or passive broadcastparticipants. Specifically, a need exists to provide a voice stream tothe endpoints connected to the conference but that do not activelyparticipate in the conference itself (i.e., do not contribute to theconference voice stream). Yet another need exists for full service audioconferencing using both high-touch (operator assisted) or reservationbased audio conferencing and automated or “ad hoc” audio conferencingusing the same platform. Specifically, a need exists to provideconferencing on a reservation basis and on an impromptu basis bymonitoring a pool of MCUs to efficiently establish conferences in thepacket-based network.

SUMMARY OF THE INVENTION

[0010] 1. Solution to the Problem. None of the prior art referencesdiscussed above disclose large-scale, fault-tolerant audio conferencingimplemented in a purely packet-switched network.

[0011] This invention provides an audio conferencing method implementedon a purely packet-switched network that provides scalability and faulttolerance.

[0012] A primary object of the present invention is to providelarge-scale, fault tolerant audio conferencing using dynamically routed,call transfer in a purely packet-switched network. That is, the presentinvention monitors a pool of MCUs so that conferences can be efficientlyestablished and routed to different MCUs when an MCU approaches capacityor when an MCU has to be taken out of service. As the audio conferencingmethod is implemented in a purely packet-switched network, thedestination of each audio packet can be rerouted seamlessly withoutinterrupting the audio conference.

[0013] Another object of the present invention is to provide an audioconferencing method for receive-only or passive participants. That is,participants that do not actively contribute to the conference can beaccommodated (i.e., receive the conference output or voice stream).

[0014] Yet another object of the present invention is to provide fullservice audio conferencing using both high-touch or reservation-basedaudio conferencing and automated or “ad hoc” audio conferencing on thesame platform. That is, a conference need not be reserved against adedicated MCU and instead, the method of the present invention allows apool of MCUs to be monitored, thus allowing for both advance conferencereservations and ad-hoc conferences.

[0015] 2. Summary. The present invention discloses a method oflarge-scale fault-tolerant audio conferencing in an audio conferencingsystem using a purely packet-switched network. According to the methodof the present invention, an endpoint places a call to a conferencegatekeeper indicating an audio conference (i.e., containing alocation-request or LRQ signal). The conference gatekeeper determineswhether the call contains sufficient information to establish the audioconference. If there is insufficient information, the endpoint isconnected to an interactive voice response (IVR) server that obtainssufficient information (i.e., an account number) from the endpoint.Either way, a conference allocation and control system (CACS) linked tothe conference gatekeeper selects an available multipoint control unit(MCU) to either host the audio conference if the audio conference hasnot been established yet, or the MCU that is already hosting the audioconference. The CACS then responds to the endpoint with routinginstructions (i.e., a location-found or LCF signal) indicating theselected MCU. The endpoint then uses the routing instructions to connectto the selected MCU, or where the endpoint was initially connected tothe IVR server to gather additional information, the endpoint istransferred from the IVR server to the selected MCU. Once connected, theMCU mixes input from all of the endpoints in the audio conference andforms a voice stream, which the MCU then returns to each endpoint in theaudio conference.

[0016] Once an audio conference is established according to the methodof the present invention, the audio conference participants (i.e.,endpoints connected to the MCU in the audio conference) can dial-outfrom the MCU to bring additional participants (i.e., another endpoint)into the audio conference. In addition, the established audio conferencesupports full service audio conferencing (i.e., both reservation-based,and ad hoc). Furthermore, the established audio conference supportsdynamic routing which permits an operator to service multiple MCUs, forthe MCUs to be geographically dispersed, and for an audio conferenceparticipant and/or an entire audio conference to be moved between MCUs..The audio conference can also be broadcast from a streaming protocolserver to passive participants. As such, the audio conferenceestablished according to the method of the present invention using apurely packet-switched network can be both large scale, and isfault-tolerant.

[0017] These and other advantages, features, and objects of the presentinvention will be more readily understood in view of the followingdetailed description and the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018]FIG. 1 is a high-level diagram of a packet-switched network foruse with the method of the present invention.

[0019]FIG. 2 is a flow chart illustrating an audio conferencing methodof the present invention.

[0020]FIG. 3 shows an example of the audio conferencing method of FIG. 2in which an IVR server is not used.

[0021]FIG. 4 shows an example of the audio conferencing method of FIG. 2in which an IVR server is used.

[0022]FIG. 5 is a flow chart illustrating a dial-out method of thepresent invention.

[0023]FIG. 6 shows an example of the dial-out method of FIG. 5.

DETAILED DESCRIPTION OF THE INVENTION

[0024] 1. Overview. FIG. 1 shows a high-level diagram of a purelypacket-switched audio conferencing system 100 using a packet network 110(e.g., Internet Protocol or IP, ATM, Frame Relay or any otherpacket-switched protocol) in which the method of the present inventioncan be implemented. The hardware is conventionally linked throughpacketized signals, as shown in FIG. 1. For purposes of illustration,control or routing signals are shown by dashed lines and audio (or voicestream) signals are shown by solid lines. An endpoint 120 (E1, E2, . . .Ei) accesses 112 the conventional packet network 110 via a gateway 130and is conventionally linked therein through a series of routers/hubs115 to a conference gatekeeper 150 (e.g., via 118).

[0025] Optionally, each endpoint 120 is also registered with agatekeeper 140 through which routing signals are sent and received suchas over links 147. Registration is conventionally used under the H.323protocol, however, registration is not required for the audioconferencing method of the present invention. The endpoint 120 can beconnected to the same gatekeeper 140 or different gatekeepers within agatekeeper cloud 145 having one or more gatekeepers 140. The gatekeeper140 is then linked 142 to the conference gatekeeper 150. The conferencegatekeeper 150 controls an MCU pool 165 having one or more conferencingMCUs 160 (MCU 1, MCU 2, . . . MCU n). The conference gatekeeper 150 isalso linked 156 to a conference allocation and control system (CACS)170. Optionally, the conference gatekeeper 150 is also linked 158 to aconventionally available interactive voice response (IVR) server 180that is capable of gathering additional routing information from theendpoint 120 via links 182, 112

[0026] In one embodiment, the conference system 100 of the presentinvention also includes a conventional streaming protocol server 185(e.g., a real-time standard broadcast server or RTSP) linked 152 to theCACS 170 and the packet network 110, a reservation system 155 linked 157to the CACS 170, and a call agent 175 linked 177 to the conferencegatekeeper. The streaming protocol server 185 is conventionallyavailable and uses the conference sum (i.e., the mixed voice stream fromall endpoints 120 actively participating in the audio conference) asinput for a broadcast signal to passive participants (i.e., endpoints120 not actively participating in the audio conference). The reservationsystem 155 is also conventionally available and used to reserve plannedaudio conferences against an available MCU 160 (i.e., an MCU havingavailable ports 190). Likewise, the call agent 175 is conventionallyavailable and manages available ports 190 in the MCU pool 165 andassigns calls on an “ad hoc” basis to available MCUs 160.

[0027] The endpoint 120 is a conventionally available client terminalthat provides real-time, two-way communications using packetized audiosignals. Packetized audio signals contain digitized and compressedspeech or touch tones. Any protocol can be used under the teachings ofthe present invention and the specific protocol will be based on designconsiderations. That is, different ITU recommendations for digitizingand compressing signals reflect different tradeoffs between speechquality, bit rate, computer power, and signal delay (e.g., G.711, G.723,etc.). It is to be expressly understood that the endpoint 120 can beeither packet-based or circuit-switched, as the gateway 130 hides thephysical transport to the endpoint 120.

[0028] The gateway 130 is optional under the teachings of the presentinvention, and when used can be a part of the packet network 110 itself.The purpose of the gateway 130 is to provide, among other things, atranslation function between conventional transmission formats (e.g.,H.323, H.225.0, H.221, etc.). It is to be expressly understood that thegateway 130 can support endpoints 120 that comply with other protocolsand the gateway 130 need only be equipped with the appropriatetranscoders. However, the gateway 130 is not required where connectionsto other networks are not needed, and the endpoint 120 then communicatesdirectly with another endpoint 120 on the same network and a singletranslation function is used.

[0029] Gatekeepers 140 (and hence the gatekeeper cloud 145) are alsooptional. Where the gatekeepers 140 are used under the teachings of thepresent invention, the purpose of gatekeepers 140 is to perform two callcontrol functions. Specifically, the gatekeeper 140 performs addresstranslation and manages bandwidth. Address translation is doneconventionally (e.g., domain name to IP address or touch tones to IPaddress) within the packet network 110 itself. Bandwidth is alsoconventionally managed within the packet network 110 itself (e.g., as IPtrunks reach capacity, the network moves audio, data, etc. signals toother lower volume IP trunks). When the gatekeeper 140 is not used,endpoints are connected through the gateway 130 (i.e., for H.323) ordirectly through the packet network 110.

[0030] The conference gatekeeper 150 in conjunction with the CACS 170controls the creation and execution of audio conferences. The CACS 170determines an available MCU 160 (i.e., having sufficient available ports190) to host the audio conference and provides routing instructions tothe conference gatekeeper 150 to direct the call from the endpoint 120to the appropriate MCU 160. For instance, if a network administrator hasspecified a threshold (i.e., in the CACS) for the number of simultaneousaudio conferences (i.e., number of active conferences, number ofavailable ports, etc.), the CACS 170 can refuse to make any moreconnections once the specified threshold is reached. In addition, theCACS 170 also provides information concerning the audio conferenceparameters to the MCU 160 and collects billing information.

[0031] The MCU 160 supports audio conferences between three or moreendpoints 120. The MCU 160 is conventionally available and consists of amultipoint controller (not shown) and optionally one or more multipointprocessors (not shown). For purposes of illustration, and not intendedto limit the scope of the present invention, four ports 190, 195 areshown on each MCU 160, although a typical MCU 160 can handleapproximately 1,500 active conference participants. Available ports 190are shown “open” while unavailable ports 195 are shown “closed”. The MCU160 handles negotiations between all endpoints 120 to determine commoncapabilities for audio processing. The MCU 160 also controls audioconference resources by determining which, if any of the audio streamswill be multicast.

[0032] With respect to the audio conferencing system 100 shown in FIG.1, an audio conference is initiated when a call identifying a particularaudio conference is placed by an endpoint 120, as explained in moredetail below. Routing signals are transmitted 112 or 147 either throughthe packet network 110 (i.e., if the gatekeeper 140 is not used) orthrough the gatekeeper 140, respectively, to the conference gatekeeper150. An MCU 160 is selected by the conference gatekeeper 150 and theCACS 170 and the audio conference is established by connecting theendpoint 120 through the packet network 110 over links 112, 114 to theMCU 160. Additional endpoints 120 can place a call identifying the audioconference and are similarly connected via links 112, 114 to theidentified audio conference over link 112 through the packet network 110to the MCU 160 by the conference gatekeeper 150 and the CACS 170, asdescribed in more detail below.

[0033] It is to be expressly understood that each of the hardwarecomponents of the purely packet-switched conferencing system 100described above are conventionally available, and it is the arrangementand/or configuration of each component in the manner described above,and the method of using each component in this configuration asexplained below that is new. Likewise, communication using packetizedsignals and various protocols is conventionally known. It is thecombination of each of the above-identified hardware components to formthe conferencing system 100 for use with the method of the presentinvention that is new. It is also to be expressly understood thatalternative hardware configurations are possible under the teachings ofthe present invention and that the method of the present invention isnot to be limited by the configuration shown in FIG. 1 nor by anyparticular network protocol.

[0034] 2. Establishing a Conference. An embodiment of the audioconferencing method of the present invention is illustrated in FIG. 2and explained with reference to FIG. 1. At step 200, an endpoint 120initiates a call to the audio conferencing system 100, for example, byentering a destination, account number, URL, or IP address. Optionallythe call is routed 147 through the gateway 130 to an address serviced bythe gatekeeper 140 in the gatekeeper cloud 145. If the gatekeeper 140 isnot used, the call is then routed 112 directly to the packet network110. Either way, the call is routed to the conference gatekeeper 150 instep 210. The initiating call contains conventional packetized controlsignals for routing the call including any audio conferenceidentification information required to initiate the audio conference(i.e., a conventional location request or LRQ). For example, seeco-owned U.S. patent application Ser. No. 09/366,355 and Ser. No.08/825,477 (hereinafter, the on-demand teleconferencing methods),incorporated herein by reference. The LRQ is received via 147, 142 (or112, 118 when the gatekeeper 140 is not used) by the conferencegatekeeper 150 which in turn queries 156 the CACS 170 for audioconference routing instructions in step 220. The CACS 170 determineswhether the call (i.e., the LRQ) contains sufficient information to setup and route the audio conference in step 230. If the call containssufficient information 232 (i.e., enough information to uniquelyidentify a subscriber, such as a subscriber identification, pass code,etc.), the CACS 170 determines whether the indicated audio conference isactive (i.e., whether other endpoints 120 are currently connected to theindicated audio conference) in step 240. That is, the CACS 170 startsall conferences with the MCU 160 and thus stores all activity in memory.If a CACS 170 is disconnected from an MCU 160, a conventional process isused to resync the CACS 170 and the MCU 160, and thus the CACS 170 iscontinuously updated with respect to activity in the MCU pool 165. Ifthe CACS 170 determines that the indicated audio conference is notactive 242, the CACS 170 selects an available MCU 160 from the MCU pool165 to host the audio conference in step 245. In step 260, the CACS 170then returns (e.g., via 156) routing information to the conferencegatekeeper 150 and the conference gatekeeper 150 responds 142, 147 (or118, 112 when gatekeeper cloud 145 is not used) to the endpoint 120 witha conventional location found signal (LCF) indicating the selected MCU160 to host the audio conference. The endpoint 120 then establishes 112,114 a point-to-point call via the packet network 110 with the selectedMCU 160 in step 270, and an audio conference is established with oneparticipant (i.e., the initiating endpoint). In step 280, the MCU 160mixes the input from all endpoints 120 participating in the audioconference, and the MCU 160 returns (e.g., via 114, 112) a voice streamto the endpoint 120 in step 290. The term “voice stream” as used herein,means the mixed sum of input from all actively participating endpointsin the conference. Further, the voice stream returned to an activelyparticipating endpoint does not include input from the same endpoint120.

[0035] Additional endpoints 120 can join an active audio conference in amanner similar to that outlined above. That is, an additional endpoint120 initiates over link 147 (or 112 when gatekeeper cloud 145 is notused) a call to an address identifying the audio conference in step 200.A conventional LRQ is sent 147, 142 (or 112, 118 when the gatekeepercloud 145 is not used) to the conference gatekeeper 150 as discussedabove. The conference gatekeeper 150 queries 156 the CACS 170 forrouting instructions in step 220. If there is sufficient information toset up and route the audio conference in step 230, the CACS 170 proceedsto determine whether the audio conference is active in step 240, selectsthe active MCU 160 in step 250 if the audio conference is active 247,and responds 156 with appropriate routing instructions to the conferencegatekeeper 150 in step 260. The conference gatekeeper 150 responds 142,147 (or 118, 112 where the gatekeeper 140 is not used) to the endpoint120 with a conventional LCF signal indicating the selected MCU 160hosting the active audio conference and the endpoint 120 establishes apoint-to-point call via links 112, 114 with the selected MCU 160 in step270, as discussed above. The MCU 160 mixes the input from each endpoint120 participating in the audio conference in step 280 and returns anappropriate voice stream over links 114, 112 to each endpoint 120 instep 290. Additional endpoints can continue to join the audio conferencein a similar manner to that just described.

[0036] An example of the audio conferencing method of the presentinvention in which there is sufficient information associated with thecall (i.e., an IVR server 180 is not required to gather additionalinformation such as an account number) is shown in FIG. 3. A new callidentifying the audio conference (e.g., containing a URL, conferenceaccess number, etc.) is placed 300 from the endpoint 120 (e.g., E1, inthis example and H.323 compliant endpoint) via link 147 to a gatekeeper140 in the gatekeeper cloud 145 (step 200). An LRQ is transmitted 310from the gatekeeper cloud 145 to the conference gatekeeper 150 via 142(step 210), which in turn requests 320 routing instructions (i.e., thedetails for the LCF) from the CACS 170 via 156 (step 220). The CACS 170selects an available MCU 160 from the MCU pool 165 (steps 230, 240, 245)and returns 325 routing instructions to the conference gatekeeper 150via link 156, which in turn forwards 330 an LCF signal through thegatekeeper cloud 145 and back 335 to the endpoint 120 (E1) via links142, 147 (steps 270, 280, and 290). The endpoint 120 (E1) uses the LCFto setup 340, 345 a point-to-point connection with the MCU 160identified by the LCF signal and establish 347 the requested audioconference (i.e., an audio conference having only the initiatingendpoint E1) via links 112, 114. For example, see the on-demandteleconferencing methods, incorporated herein by reference. Additionalendpoints 120 (i.e., E2) join the established audio conference 347 asfollows. A new call identifying the established audio conference 347 isplaced 350 to the gatekeeper cloud 150 via link 147 (step 200). An LRQis transmitted 360 from the gatekeeper cloud 145 to the conferencegatekeeper 150 via link 142 (step 210), which in turn requests 370routing instructions to the established audio conference from the CACS170 via link 156 (step 220). The CACS 170 selects the active MCU 160identified as hosting the requested audio conference (steps 230, 240,and 250) and returns 375 routing instructions identifying the MCU 160hosting the audio conference 347 to the conference gatekeeper 150 vialink 156, which in turn forwards 380, 385 an LCF signal through thegatekeeper cloud 145 to the endpoint 120 (E2) via links 142, 147 (step260). The endpoint 120 (E2) uses the routing information from the LCF toestablish a connection 390, 395 to the appropriate MCU 160 (via 112,114), and an active audio conference 397 is established (i.e., betweenE1 and E2) (steps 270, 280, and 290). Additional endpoints 120 (E3, E4,. . . Ei) can participate in the active audio conference 397 byaccessing the appropriate MCU 160 as just described with respect to theendpoint 120 (E2) or through a dial out request, as described below. Itis to be expressly understood that the above example is presented to beillustrative of the audio conferencing method of the present invention,and in no way should be interpreted to limit the scope of the presentinvention.

[0037] In another embodiment, also shown in FIG. 2, where the call doesnot contain sufficient information 237 (i.e., additional informationsuch as an account number is required), the endpoint 120 must firstconnect (via links 112, 182) to an IVR server 180 capable of gatheringthe required information in step 235 (e.g., by querying the endpoint 120for an account number). Routing proceeds as described above with respectto steps 240 through 260 and in step 270, the endpoint 120 is thentransferred from the IVR server 180 to the MCU 160 selected in step 245or 250 before mixing the input and returning a voice stream in steps 280and 290, respectively. Thus, there is no requirement to collocate thedevice gathering the information and the MCU 160 which will be the finaldestination.

[0038] An example of the audio conferencing method of the presentinvention in which an IVR server 180 is used is shown in FIG. 4. Steps300, 310 and 320 in FIG. 4 correspond to those shown in FIG. 3. However,in FIG. 4, the CACS determines that the routing request containsinsufficient information to establish an audio conference. Hence, asignal is returned 325, 330, and 335 via links 118, 112 to the endpoint120 (E1) to route the endpoint 120 (E1) to an IVR server 180. Theendpoint 120 (E1) establishes a connection with the IVR server 180 (400and 405), and the IVR server 180 gathers 410 additional information(e.g., an account number) from the endpoint 120 (E1) to establish anaudio conference (step 235). Once the IVR server 180 has gathered thisinformation, the IVR server 180 sends 420 a routing request to the CACS170 via links 158, 156, which in turn returns 425 routing information tothe IVR server 180 (steps 240, 245, and 260). Based on the routinginformation, the call is then transferred 430 from the IVR server 180and a point-to-point connection is established 340, 345 between theendpoint 120 (E1) and the MCU 160 and an audio conference 347 isestablished via links 112, 114 (steps 270, 280, and 290). Additionalendpoints 120 (e.g., E2) join the audio conference again by placing 350a call through 360 the gatekeeper cloud 145 to the conference gatekeeper150 (step 200). Again, the conference gatekeeper 150 requests 370routing information from the CACS 170 and is provided 375 with routinginformation to an IVR server for obtaining additional information fromthe endpoint 120 (E2) (steps 210, 220, 230, 237). The LCF is transmitted380, 385 to the endpoint 120 (E2) and a call is established 440, 445between the endpoint 120 (E2) and the IVR server 180. The IVR server 180gathers 450 the additional information (i.e., an account number, accesscode, etc.) from the endpoint 120 (E2) and transmits 460 a routingrequest to the CACS 170 (step 235). The CACS 170 responds 465 withrouting information identifying the MCU 160 hosting the audioconference, and the call is then transferred from the IVR server 180 tothe identified MCU 160, a point-to-point connection 470 is establishedbetween the endpoint 120 (E2) (steps 240 to 290 discussed above). It isto be expressly understood that the above example is presented to beillustrative of the audio conferencing method of the present invention,and in no way should be interpreted to limit the scope of the presentinvention.

[0039] Communication with the gateway 130 and the gatekeeper 140, andaddress resolution is conventional. Furthermore, it is to be expresslyunderstood that the use of the gateway 130 and the gatekeeper 140 isoptional and need not be used under the teachings of the presentinvention. In an embodiment where the gateway 130 and the gatekeeper 140are not used, the call is routed directly through the packet network 110(e.g., between routers/hubs 115). 3. Dial-out Method. An embodiment ofthe dial-out method of the present invention is illustrated in FIG. 5.The dial-out method is used to connect to an endpoint 120 not currentlyconnected to an active audio conference. For example, the dial-outmethod can be used when an active audio conference exists 500 betweenconference participants (e.g., E1, E2, and E3) and the conferenceparticipants wish to bring in an additional participant (e.g., E4).

[0040] In step 510, a conference participant conventionally initiatesthe dial-out from an originating endpoint 120 (e.g., E1, via touch toneor a web interface) and the CACS 170 requests a dial-out from the MCU160 and supplies the MCU 160 with the address of the endpoint 120 toconnect to (e.g., E4). The MCU 160 initiates (via 154) a new callrequest to the conference gatekeeper 150 in step 520. In step 530, thegatekeeper 140 (or packet network 110 when cloud 145 is not used)receives an LRQ from the conference gatekeeper 150 and in step 540 thegatekeeper 140 (or packet network 110) returns the destination address(i.e., via an LCF message) which is forwarded 154 to the MCU 160 fromthe conference gatekeeper 150. The MCU 160 then establishes apoint-to-point call to the endpoint 120 (E4) and mixes the input to forma voice stream for all conference participants (E1-E4) in step 550,similar to that described above with respect to the audio conferencingmethod. Thus, the additional participant (E4) is brought into the activeaudio conference. If the additional participant (E4) does not answer thedial-out request, the line is disconnected by the originating endpoint120 (E1) and the originating endpoint 120 (E1) is placed back in theaudio conference.

[0041] An example of the dial-out method of the present invention isshown in FIG. 6. In this example, an active audio conference 397 hasalready been established (e.g., according to the method of establishingan audio conference discussed above), and the existing participants(e.g., E1-E3) wish to bring in an additional endpoint 120 (E4) toparticipate in the active audio conference 397 (step 500). An initiatingendpoint (i.e., E1) places a call identifying the additional endpoint(E4) and the CACS 170 requests 600 a dial-out from the MCU 160 (step510). The MCU 160 transmits 610 the new call to the conferencegatekeeper 150 via link 154 (step 520), which in turn requests 620 thelocation of the desired endpoint 120 (E4) from the gatekeeper cloud (via142). The gatekeeper cloud 145 responds 630 via link 142 (step 530) tothe conference gatekeeper 150 with an LCF signal which is in turntransmitted 635 to the MCU 160 via link 154 (step 540). The MCU 160 thenuses the information from the LCF to establish 640, 645 a point-to-pointcall between the MCU 160 and the endpoint 120 (E4) via links 114, 112.Hence, the endpoint 120 (E4) is brought into the active audio conference650 as an additional participant (step 550). It is to be expresslyunderstood that the above example is presented to be illustrative of theaudio conferencing method of the present invention, and in no way shouldbe interpreted to limit the scope of the present invention.

[0042] 4. Full Service Audio Conferencing. Planned audio conferencingconventionally requires an advance reservation against a specific MCU160 or MCU pool 165 and operator assistance (i.e., high-touch) tofacilitate the audio conference. Ad-hoc audio conferencingconventionally is able to support an audio conference without areservation and without operator assistance by creating a conferenceagainst a single MCU 160. On the other hand, once an audio conference isestablished according to the method of the present invention, the audioconferencing system 100 offers full service audio conferencing thatsupports both planned and ad-hoc audio conferencing.

[0043] The method of the present invention implements full service audioconferencing by integrating the reservation system 155 of the plannedaudio conferencing system and the call agent 175 of the ad-hoc system.Ports 190, 195 utilized for each audio conferencing type can bedynamically driven by current loads to achieve maximum port utilization.

[0044] In one embodiment, the reservation system 155 and the call agent175 are loosely integrated. That is, the master reservation system 155conventionally used to reserve planned audio conferences on specificMCUs 160 in pool 165 keeps the ad-hoc call agent 175 informed as to thenumber of available ports 190 on each MCU 160 and the ad hoc call agent175 conventionally manages the available ports 190. The number ofavailable ports 190 on a given MCU 160 are conventionally monitored toensure that all reservations can be serviced. For example, an availableport 190 that will be required to support a reservation in the next fiveminutes is not considered available (i.e., 195). Likewise, statisticallyexpected ad-hoc usage is also monitored and accounted for.

[0045] In another embodiment, the reservation system 155 and the callagent 175 are tightly integrated. That is, the reservation system 155 isused to reserve planned audio conferences against MCU pool 165 but thereservation is not bound to a specific MCU 160. Instead, the audioconference is assigned to an MCU 160 by the call agent 175 when it iscreated and the call agent 175 continuously monitors the port 190, 195usage and anticipated near term usage (i.e., reserved ports) of each MCU160 in the pool 165 to determine the number and location of availableports 190. When an audio conference needs to be created (either aplanned audio conference or an ad-hoc audio conference), the call agent175 selects an appropriate MCU 160 to host the audio conference andensures that all calls for a given audio conference are routed to theappropriate MCU 160. Thus, the call agent 175 determines the location ofall audio conferences allowing for greater port 190, 195 utilization aswell as better fault tolerance (i.e., audio conference requests willseldom be denied because available ports 190 are closely monitored).

[0046] 5. Network Centric Call Transfer and Dynamic Call Routing. Oncean audio conference is established according to the method of thepresent invention, the packet-switched audio conference system 100 alsofacilitates dynamic call routing. A point-to-point connection is madeusing logical links (i.e., within the packet network 110) and adedicated physical connection is not required (i.e., as in a GSTN). Thatis, the call data and associated control are sent via packets throughthe packet network 110 and each packet is sent individually to adestination address so that the physical route taken from end-to-end mayvary from packet to packet (i.e., a call can be routed or transferred bysimply renegotiating the destination address).

[0047] Thus, under the teachings of the present invention, calls can berouted to any MCU 160 within the MCU pool 165 allowing MCUs 160 to begeographically distributed and the audio conference network 100 to belarge-scale. In addition, the ability to transfer a call from one MCU160 to another allows the operator voice path to be routed to any MCU160 in the conference system 100. This in turn allows an operator toservice a large number of MCUs 160 and to quickly switch which MCU 160their voice path terminates on.

[0048] In addition, an audio conference established according to themethod of the present invention allows an audio conference participantto be moved from one audio conference to another, even where the audioconferences are on separate MCUs 160. The destination address of thepackets are simply renegotiated to another MCU 160 instead ofestablishing a connection between the two MCUs 160.

[0049] An audio conference established according to the method of thepresent invention also allows a new audio conference to be created on adifferent MCU 160 where an MCU 160 is taken out of service or otherwiseunavailable to take additional participants (e.g., due to overflow,etc.). By transferring calls, the audio conference can be serviced byany MCU 160 in the system 100. All calls destined for a “moved” audioconference are still statically routed to the original MCU 160, butimmediately transferred to the correct MCU 160, thus service to theaudio conference is not interrupted.

[0050] 6. Receive Only Support. Audio conference participants can beeither active or passive. Participants that can both contribute to andreceive audio input from an audio conference are active participants.Those that can only receive a voice stream from an audio conference arepassive participants. Once an audio conference is established accordingto the method of the present invention, the audio conference supportsboth active and passive participants.

[0051] Support for passive participants can still be provided wherethere are only a limited number of participants by the MCU 160 the sameas it is in a conventional circuit-switched network. That is, a fullduplex connection can be established and the receive path simplyignored. However, the method of the present invention can also usebroadcasting to support passive participants. That is, the audioconference output is directed to a streaming protocol server 185 (e.g.,a real-time standard broadcast server RTSP). The streaming protocolserver 185 uses the audio conference sum as its input, and passiveparticipants can connect to the streaming protocol server 185 usingconventional standards of service. As such, a large number of broadcastprotocols can be supported, and a virtually unlimited number of passiveparticipants can be supported with little or no impact on theconferencing MCU 160.

[0052] The foregoing discussion of the invention has been presented forpurposes of illustration and description. Further, the description isnot intended to limit the invention to the form disclosed herein.Consequently, variation and modification commensurate with the aboveteachings, within the skill and knowledge of the relevant art, arewithin the scope of the present invention. The embodiment describedherein and above is further intended to explain the best mode presentlyknown of practicing the invention and to enable others skilled in theart to utilize the invention as such, or in other embodiments, and withthe various modifications required by their particular application oruses of the invention. It is intended that the appended claims beconstrued to include alternate embodiments to the extent permitted bythe prior art.

We claim:
 1. A method of large-scale fault-tolerant audio conferencingin a purely packet-switched audio conferencing system, said methodcomprising the steps of: placing a call from an endpoint to a conferencegatekeeper, said call indicating an audio conference; querying a CACSfrom said conference gatekeeper for routing instructions for said audioconference; determining in said CACS whether said audio conference isactive; selecting in said CACS an MCU to host said audio conference whensaid audio conference is inactive; selecting in said CACS an MCU hostingsaid audio conference when said audio conference is active; respondingfrom said CACS to said endpoint with said queried routing instructions,said queried routing instructions indicating said selected MCU;connecting said endpoint to said selected MCU; mixing input from allendpoints in said audio conference to form a voice stream; and returningsaid voice stream to each endpoint in said audio conference.
 2. Themethod of claim 1 wherein the step of placing a call links said endpointto said conference gatekeeper through a gatekeeper cloud.
 3. The methodof claim 1 wherein the step of placing a call links said endpoint tosaid conference gatekeeper through said packet-switched network.
 4. Themethod of claim 1 wherein the routing instructions include at least anLCF signal indicating the selected MCU.
 5. The method of claim 1 whereinthe call includes at least an LRQ signal.
 6. The method of claim 1further comprising the steps of: determining in said CACS whether thecall from said endpoint contains adequate information to establish saidaudio conference; responding from said CACS to said endpoint withrouting instructions to an IVR server when there is inadequateinformation to establish said audio conference; connecting said endpointto said IVR server when there is inadequate information to route saidcall; gathering in said IVR server, after connecting said endpoint tosaid IVR server, adequate information to establish said audioconference; and transferring said endpoint from said IVR server to saidselected MCU after said IVR server gathers said adequate information. 7.The method of claim 1 further having a dial-out method comprising thesteps of: initiating a call request from said selected MCU to saidconference gatekeeper, said call request indicating an additionalendpoint; transmitting an LRQ from the conference gatekeeper to thegatekeeper cloud; returning a destination address to said conferencegatekeeper from said gatekeeper cloud, said destination addresscorresponding to said additional endpoint; forwarding said destinationaddress from said conference gatekeeper to said selected MCU;establishing a point-to-point call from said MCU to said additionalendpoint based on said destination address, thereby bringing saidadditional endpoint into said audio conference.
 8. The method of claim 1further supporting full service audio conferencing using a reservationsystem and a call agent.
 9. The method of claim 8 wherein thereservation system and the call agent are tightly integrated.
 10. Themethod of claim 8 wherein the reservation system and the call agent areloosely integrated.
 11. The method of claim 1 wherein said selected MCUis selected from an MCU pool.
 12. The method of claim 1 furtherincluding the step of dynamically routing an operator voice path toservice multiple MCUs.
 13. The method of claim 1 further including thestep of renegotiating the destination of a voice path to move an audioconference participant from said selected MCU to a second MCU.
 14. Themethod of claim 1 further including the step of moving said audioconference from said selected MCU to a second MCU.
 15. The method ofclaim 1 further including the steps of: providing said audio conferenceto a streaming protocol server from said selected MCU; connecting apassive participant to said streaming protocol server; and broadcastingsaid audio conference from said streaming protocol server to a passiveparticipant.
 16. A large-scale fault-tolerant purely packet-switchedaudio conferencing method, said method comprising the steps of:establishing an audio conference by: connecting an endpoint to aconference gatekeeper, said endpoint indicating an audio conference;querying a CACS from said conference gatekeeper for routing instructionsfor said audio conference; determining in said CACS the status of saidaudio conference; selecting in said CACS an MCU to host said audioconference when said status of said audio conference is inactive;selecting in said CACS an MCU hosting said audio conference when saidstatus of said audio conference is active; responding from said CACS tosaid endpoint with said queried routing instructions, said queriedrouting instructions indicating said selected MCU; connecting saidendpoint to said audio conference through said selected MCU; mixinginput from all endpoints in said audio conference to form a voicestream; returning said voice stream to each endpoint in said audioconference; and dialing out from the audio conference when said statusof said audio conference is active to connect additional endpoints tothe audio conference by: initiating in the endpoint connected to saidaudio conference a call request from said selected MCU to saidconference gatekeeper, said call request indicating said additionalendpoint; transmitting an LRQ from the conference gatekeeper to thegatekeeper cloud; returning a destination address to said conferencegatekeeper from said gatekeeper cloud, said destination addresscorresponding to said additional endpoint; forwarding said destinationaddress from said conference gatekeeper to said selected MCU;establishing a point-to-point call from said MCU to said additionalendpoint based on said destination address, thereby bringing saidadditional endpoint into said audio conference.
 17. The method of claim16 further comprising the steps of: determining in said CACS whether thecall from said endpoint contains adequate information to establish saidaudio conference; responding from said CACS to said endpoint withrouting instructions to an IVR server when there is inadequateinformation to establish said audio conference; connecting said endpointto said IVR server when there is inadequate information to route saidcall; gathering in said IVR server, after connecting said endpoint tosaid IVR server, adequate information to establish said audioconference; and transferring said endpoint from said IVR server to saidselected MCU after said IVR server gathers said adequate information.18. The method of claim 16 further supporting full service audioconferencing using a reservation system and a call agent.
 19. The methodof claim 16 wherein said selected MCU is selected from an MCU pool. 20.The method of claim 16 further including the step of dynamically routingan operator voice path to service multiple MCUs.
 21. The method of claim16 further including the step of renegotiating the destination of avoice path to move an audio conference participant from said selectedMCU to a second MCU.
 22. The method of claim 16 further including thestep of moving said audio conference from said selected MCU to a secondMCU.
 23. The method of claim 16 further including the steps of:providing said audio conference to a streaming protocol server from saidselected MCU; connecting a passive participant to said streamingprotocol server; and broadcasting said audio conference from saidstreaming protocol server to a passive participant.
 24. A large-scalefault-tolerant audio conferencing method over a purely packet-switchednetwork, said method comprising the steps of: initiating a call from anendpoint to a conference gatekeeper; querying a CACS from saidconference gatekeeper for routing instructions for an audio conference;determining in said CACS whether the call from said endpoint containsadequate information to establish said audio conference; responding fromsaid CACS to said endpoint with routing instructions to an IVR serverwhen there is inadequate information to establish said audio conference;connecting said endpoint to said IVR server when there is inadequateinformation to route said call and: gathering in said IVR serveradequate information to establish said audio conference; andtransferring said adequate information to the CACS; determining in saidCACS the status of said audio conference; selecting in said CACS an MCUto host said audio conference when said status of said audio conferenceis inactive; selecting in said CACS an MCU hosting said audio conferencewhen said status of said audio conference is active; responding fromsaid CACS to said endpoint with said queried routing instructions, saidqueried routing instructions indicating said selected MCU; transferringsaid endpoint from said IVR server to said audio conference at saidselected MCU when there is inadequate information to route the call; andconnecting said endpoint to said audio conference at said MCU when thereis adequate information to route the call.
 25. The method of claim 24further supporting full service audio conferencing using a reservationsystem and a call agent.
 26. The method of claim 24 wherein saidselected MCU is selected from an MCU pool.
 27. The method of claim 24further including the step of dynamically routing an operator voice pathto service multiple MCUs.
 28. The method of claim 24 further includingthe step of renegotiating the destination of a voice path to move anaudio conference participant from said selected MCU to a second MCU. 29.The method of claim 24 further including the step of moving said audioconference from said selected MCU to a second MCU.
 30. The method ofclaim 24 further including the steps of: providing said audio conferenceto a streaming protocol server from said selected MCU; connecting apassive participant to said streaming protocol server; and broadcastingsaid audio conference from said streaming protocol server to a passiveparticipant.
 31. A large-scale fault-tolerant audio conferencing methodin a purely packet-switched network, said method comprising the stepsof: initiating a call from an endpoint to a conference gatekeeper in agatekeeper cloud; querying a CACS from said conference gatekeeper forrouting instructions for an audio conference; determining in said CACSwhether the call from said endpoint contains adequate information toestablish said audio conference; responding from said CACS to saidendpoint with routing instructions to an IVR server when there isinadequate information to establish said audio conference; connectingsaid endpoint to said IVR server when there is inadequate information toroute said call and: gathering in said IVR server adequate informationto establish said audio conference; and transferring said adequateinformation to the CACS; determining in said CACS the status of saidaudio conference; selecting in said CACS a conference MCU from an MCUpool, said conference MCU hosting said audio conference when said statusof said audio conference is inactive; selecting in said CACS aconference MCU from an MCU pool, said conference MCU hosting said audioconference when said status of said audio conference is active;responding from said CACS to said endpoint with said queried routinginstructions, said queried routing instructions indicating said selectedMCU; transferring said endpoint from said IVR server to said audioconference at said selected conference MCU when there is inadequateinformation to route the call; connecting said endpoint to said audioconference at said conference MCU when there is adequate information toroute the call, once said endpoint is connected to said audioconference, said audio conference: supporting full service conferencingin said audio conference to said endpoint with a reservation system anda call agent; supporting dynamically routed audio signals within saidpacket-switched network; supporting passive participants in saidpacket-switched network supporting dial out from said audio conferenceto an additional endpoint.